https://linen.dev logo
Join Slack
Powered by
Hi! I just opened an issue for a CJK font renderin...
# community-contributors
y
Hi! I just opened an issue for a CJK font rendering bug in scheduled deliveries and screenshots: https://github.com/lightdash/lightdash/issues/21499 Japanese text renders with a Chinese font (WenQuanYi Zen Hei) instead of Noto Sans CJK JP in the headless browser container. The fix is a one-line CSS change — adding 
'Noto Sans CJK JP'
to the font-family stack in 
mantineTheme.ts
. I've verified it locally and would like to work on the PR. 🙋
✅ 1
Added a note on the issue: the proposed 
font-family
fix favors JP, which has the same structural bias as the current state (favoring Chinese/WenQuanYi). A more comprehensive fix would be setting 
<html lang="...">
based on user locale when taking headless browser screenshots — this ties into i18n support (#5026).
o
Hey 👋 Thanks for the details, I'll speak to the team and get back to you here!
electric mint heart 1
m
@Yasuhiro Arakaki if I am understanding this correctly "it has the same structural limitation as the current state — it favors one CJK language variant over others.", making the first proposed change will 'break' Chinese rendering, right? So we have to do something like the `<html lang="...">`suggestion
y
@Marshall Agnew Exactly. Instead of a hardcoded font-family fix, we should add a language setting at the organization level or project level. ​By injecting this locale into the html lang="..." attribute during rendering (e.g., when taking screenshots or generating PDFs), we can ensure the browser handles font fallback correctly for each language without introducing any structural bias. ​I'll focus on implementing this configuration-based approach as part of our i18n support (#5026).
Just to add, the current rendering issues with Japanese characters are causing significant practical problems for us, and it's quite frustrating in our daily use. ​I’m committed to moving forward with the organization-level locale setting to ensure the proper <html lang="..."> injection, as it’s becoming a high priority for us to get this resolved as soon as possible.
Alternatively, we could take a more minimal approach by including a language option directly within the image delivery/rendering settings. ​This would allow us to inject the correct lang attribute specifically for the screenshot/PDF generation process without needing to implement a full-scale organization-wide configuration right away. Given that the current Japanese rendering is causing significant practical issues for us, this might be a faster way to get a reliable fix in place.
m
If there is a faster less-overhead solution that makes things work better for you, that is definitely the way I'd go. A full i18n solution is not really in the plans at the moment, but we are all for addressing this if it's causing major issues for you.
y
Thanks for the support. I agree that a minimal approach is the best way forward for now. ​I’ll update the issue description to reflect this plan: adding a lang option specifically for the rendering process (screenshots/PDFs) to inject the correct <html lang="..."> attribute. > This solves the Japanese rendering issue with minimal overhead and avoids the structural bias we discussed. I’ll start working on a PR based on this approach.
applause 1
m
Great. Let us know when you have a PR and we can take a look.
electric mint heart 1
y
PR is up: https://github.com/lightdash/lightdash/pull/21541 Interesting finding during implementation — Chromium on Linux ignores fontconfig entirely and uses its own hardcoded font fallback, so the original approach (injecting 
<html lang>
+ relying on fontconfig) didn't work. The fix uses CSS 
:lang()
selectors to explicitly map each CJK language to the correct Noto Sans CJK variant. Backend sets the 
lang
attribute via 
page.evaluate()
after navigation.
m
@Yasuhiro Arakaki Ok, great, we will take a look. Can you add repro steps to the PR so that we can try it correctly and make sure it works? Like steps a human can take to verify. Thanks!
y
@Marshall Agnew Thanks for looking into it! Here are the repro steps: https://github.com/lightdash/lightdash/pull/21541#issuecomment-4161171501
One note on testing — if you're not familiar with CJK scripts, the difference might be subtle at first glance. The key thing to look for is the glyph shapes of kanji characters. Chinese, Japanese, and Korean share many of the same Unicode code points, but the correct stroke shapes differ by language — just as "color" vs "colour" are both valid but belong to different locales. With the bug, Japanese text is rendered using Chinese glyph shapes, which native readers immediately recognize as wrong. The fix selects the correct regional font variant.
thank you 1
m
@Yasuhiro Arakaki I just want to let you know that we haven't forgotten about this, but we didnt get to it yet. Thank you for the PR, we will look as soon as we can 🙇
🤝 1
5 Views
Open in Slack
PreviousNext
Powered by